Congestion alleviation in network systems

ABSTRACT

In one embodiment, a method is provided for alleviating congestion in a network system. In this method, the receipt of data packets destined for a destination apparatus is detected. Flow control signals are also received with each flow control signal corresponding to a data packet. Various time periods are tracked with each time period being between the detection of the receipt of a data packet and the receipt of tracked corresponding flow control signal. An average of the time periods is calculated and this average is compared to a threshold. One or more data packets are dropped in reference to the comparison.

FIELD

The present disclosure relates generally to communication systems.

BACKGROUND

Data packets are transmitted within a network system, such as a FibreChannel network. To prevent a recipient device (e.g., a storage server)from being overwhelmed with incoming data packets, many network systemsprovide flow control mechanisms based on, for example, a system ofbuffer-to-buffer credits. Each buffer-to-buffer credit represents theability of a recipient device to accept additional data packets. If arecipient device issues no credits to the sender, the sender cannot sendany additional data packet. This control of the data packet flows basedon buffer-to-buffer credits helps prevent the loss of data packets andalso reduces the frequency of need of data packets to be retransmittedacross the network system. It should be appreciated that switches thatconnect various network segments in the network system buffer allincoming data packets. In particular, data packets from input queue aretransferred to egress queue through a loss arbitration system. When arecipient apparatus is slow, this egress queue becomes full, which canresult in the ingress queue becoming full too. Such data packets consumeall buffer-to-buffer credits causing blocking of flows destined to otherrecipient apparatuses.

BRIEF DESCRIPTION OF DRAWINGS

The present disclosure is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a block diagram depicting a network system for communicatingdata packets, in accordance with an example embodiment;

FIG. 2 depicts an example of an output queue included in a switchingapparatus, such as the switching apparatus depicted in FIG. 1;

FIG. 3 is a block diagram illustrating an example embodiment of a systemof switching apparatuses that is configured for congestion control in anetwork system;

FIG. 4 is a flow diagram of a general overview of a method, inaccordance with an example embodiment, for alleviation of congestion ina network system;

FIG. 5 is a timing diagram depicting various data transmitted betweencomponents in a Fibre Channel network system that supports congestionalleviation, in accordance with an example embodiment; and

FIG. 6 is a flow diagram depicting a more detailed method, in accordancewith an alternative embodiment, for congestion alleviation in a FibreChannel network system; and

FIG. 7 is a flow diagram depicting a method, in accordance with analternative embodiment, for dropping data packets at the input queue.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of an example embodiment of the present disclosure. Itwill be evident, however, to one skilled in the art that the presentdisclosure may be practiced without these specific details.

Overview

A method is provided for alleviating congestion in a network system. Inthis method, the receipt of data packets destined for a destinationapparatus is detected. Flow control signals are also received with eachflow control signal corresponding to a data packet. Various time periodsare tracked with each time period being between the detection of thereceipt of a data packet and the receipt of tracked corresponding flowcontrol signal. An average of the time periods is calculated and thisaverage is compared to a threshold. One or more data packets are droppedin reference to the comparison.

Example Embodiments

FIG. 1 is a block diagram depicting a network system 100 forcommunicating data packets, in accordance with an example embodiment.The network system 100 includes edge apparatuses 102.1-102.4 andswitching apparatuses 150.1-150.2. In one example, the network system100 can be a storage area network (SAN), which is a high-speed networkthat enables establishment of direct connections between storage systemand its storage devices. The SAN may thus be viewed as an extension to astorage bus and, as such, an operating system of storage system enablesaccess to stored data using block-based access protocols over anextended bus. In this context, the extended bus can be embodied as FibreChannel, Computer System Interface (SCSI), Internet SCSI (iSCSI) orother network technologies.

As depicted, the edge apparatuses 102.1 and 102.2 are transmitting datapackets 160′ and 161′ to edge apparatuses 102.3 and 102.4, respectively,by way of switching apparatuses 150.1 and 150.2. As explained in detailbelow, the switching apparatuses 150.1 and 150.2 are computer networkingapparatuses that connect various network segments. In this example, theflow of packets 161′ to edge apparatus 102.4 is congested because, forexample, this particular edge apparatus 102.4 cannot process the datapackets as fast as the packets are received. However, this congestionassociated with edge apparatus 102.4 can negatively affect the flow ofdata packets to other edge apparatuses as well, such flow of datapackets 160′ to edge apparatus 102.3.

In particular, congestion can affect other flows because of how flowcontrol signals are buffered in the network system 100. In general, flowcontrol refers to stopping or resuming transmission of data packets. A“flow control signal,” as used herein, refers to a signal transmittedbetween two apparatuses to control the flow of data packets between eachother. An example of a flow control signal is a pause command (or pauseframe) used in Ethernet flow control. It should be appreciated thatpause command signals the other end of the connection to pausetransmission for a certain amount of time, which is specified in thecommand.

Another example of a flow control signal is a buffer-to-buffer creditused in Fibre Channel flow control. A “buffer-to-buffer credit,” as usedherein, identifies a number of data packets that are allowed toaccumulate on a destination apparatus. Particularly, in buffer-to-buffercredit control, two connected apparatuses in the network system 100(e.g., switching apparatus 150.2 and edge apparatus 102.4 or switchingapparatuses 150.1 and 150.2) set a number of unacknowledged framesallowed to accumulate before a sending apparatus, which initiatestransmission, stops sending data to a destination apparatus, whichreceives the frames. It should be appreciated that a “frame,” refers toa data packet that includes frame synchronization. Thus, in effect, aframe is a data packet and therefore, the terms may be usedinterchangeably.

A counter at the sending apparatus keeps track of a number ofbuffer-to-buffer credits. Each time a frame is sent by the sendingapparatus, the counter increments by one. Each time the destinationapparatus receives a frame, it sends an acknowledgement back to thesending apparatus, which decrements the counter by one. If the number ofbuffer-to-buffer credits reaches a maximum limit, the sending apparatusstops transmission until it receives a next acknowledgement from thedestination apparatus. As a result, the use of such buffer-to-buffercredit mechanism prevents loss of frames that may result if the sendingapparatus races too far ahead of a destination apparatus's ability toprocess the frames.

It should be appreciated that buffer-to-buffer credit limit reaching amaximum is equivalent to receiving a pause command, which is describedabove. In Ethernet flow control, an edge device 102.4, which processesdata packets slower than switching apparatus 150.2, causes the outputqueue in the switching apparatus 150.2 to fill up. As a result, in asystem with lossless arbitration scheme, the input queue in theswitching apparatus 105.2 is also filled up. When the input queue fillsup, the switching apparatus 105.2 flow controls switching apparatus150.1 that causes congestion for all the flows destined to switchingapparatus 150.2.

FIG. 2 depicts an example of an output queue 200 included in a switchingapparatus, such as the switching apparatus 150.1 depicted in FIG. 1. Inreference to FIG. 2, this output queue 200 is configured to bufferframes outputted to various ports, such as ports 161-166. As usedherein, a “port” refers to a logical channel or channel endpoint in anetwork system. For example, a Fibre Channel port is a hardware pathwayinto and out of a node that performs data communications over a FibreChannel link.

Given that the output queue 200 buffers all frames to multiple ports161-166, in the event of a congestion of an output port, all thebuffered frames behind the congested port are blocked or delayed. Forexample, port 166 is destined to an apparatus that processes its datapackets slower than the other destination apparatuses. Thus, a flow offrames to port 166 becomes congested and therefore, the transmission ofother frames to the same port 166 as stored in the output queue 200 isdelayed. However, all the frames to other ports 161-165 are also storedand queued in the output queue 200, but cannot move up in the queueuntil the top of the queue, which includes frame to port 166, has beencleared. Thus, as depicted in FIG. 2, the delay in clearing frames toport 166 from the output queue 200 also delays or blocks transmission offrames to other ports 161-165.

FIG. 3 is a block diagram illustrating an example embodiment of a system300 of switching apparatuses (e.g., switching apparatus 150) that isconfigured for congestion control in a network system. It should beappreciated that this embodiment of the switching apparatus 150 may beincluded in, for example, the network system depicted in FIG. 1.Referring back to FIG. 3, in various embodiments, the switchingapparatus 150 may be used to implement computer programs, logic,applications, methods, or processes to control congestion in a networksystem, as described in detail below.

The switching apparatus 150 is a device that channels incoming datapackets 350 from multiple input ports to one or more output ports thatforward the output data packets 351 toward their intended destinations.For example, on an Ethernet local area network (LAN), the switchingapparatus 150 determines which output port to forward each incoming datapacket 350 based on the physical device address (e.g., Media AccessControl (MAC) address). In a Fibre Channel network, data packets areforwarded based on a Fibre Channel destination index. In an Open SystemsInterconnection (OSI) communications model, the switching apparatus 150performs the Layer 2 or Data-link layer function. In another example,the switching apparatus 150 can also perform routing functionsassociated with Layer 3 or network layer functions in OSI.

In this embodiment, the switching apparatus 150 includes a physicallayer and address module 302, a forwarding module 304, a queuing model306, and a crossbar module 350. In general, the physical layer andaddress module 302 converts, for example, optical signals received intoelectrical signals, and sends the electrical stream of bits into, forexample, the MAC, which is included in the physical layer and addressmodule 302. The primary function of the MAC is to decipher Fibre Channeldata packets from the incoming bit stream. In conjunction with datapackets being received, the MAC communicates with the forwarding andqueuing modules 304 and 306, respectively, and issues returnbuffer-to-buffer credits to the sending apparatus to recredit thereceived data packets. Additionally, as explained in detail below, thephysical layer and address module 302 includes port logic module 310that, as one of its function, is configured for congestion control.

The forwarding module 304 is configured to determine which output porton the switching apparatus 150 to send the incoming data packets 350.The forwarding can be based on a variety of lookup mechanisms, such asper-virtual storage area network (VSAN) forwarding table lookup,statistics lookup, and per-VSAN Access Control Lists (ACL) lookup.

The queuing module 306 is primarily configured to schedule the flow ofdata packets through the switching apparatus 150. As described above,queuing module 306 provides frame buffering for queuing of received datapackets. In one embodiment, as explained in detail below, the port logicmodule 310 can provide instructions related to congestion control to thequeuing module 306.

Additionally, system 300 depicts multiple switching apparatuses, each ofwhich can be linked together by the crossbar module 350. In this system300, data packets can be transferred from the input queue to the outputqueue through the crossbar module 350 by way of a lossless arbitrationmechanism.

It should be appreciated that in other embodiments, the switchingapparatus 150 may include fewer or more modules apart from those shownin FIG. 3. The modules 302, 304, 306, and 310 may be in the form offirmware that is processed by application specific integrated circuits(ASIC), which may be integrated into a circuit board. Alternatively, themodules 302, 304, 306, and 310 may be in the form of one or more logicblocks included in a programmable logic device (e.g., a fieldprogrammable gate array). The described modules 302, 304, 306, and 310may be adapted, and/or additional structures may be provided, to providealternative or additional functionalities beyond those specificallydiscussed in reference to FIG. 3. Examples of such alternative oradditional functionalities will be discussed in reference to the flowdiagrams discussed below.

FIG. 4 is a flow diagram of a general overview of a method 400, inaccordance with an example embodiment, for alleviation of congestion ina network system. In an example embodiment, the method 400 may beimplemented by the port logic module 310 employed in the switchingapparatus 150 depicted in FIG. 3.

As depicted, in FIG. 4, the port logic module detects receipt of datapackets, at 402, that are destined for or to be forwarded to adestination apparatus. In one embodiment, the port logic module can makesuch a detection by detecting whether the data packets are stored in anoutput queue.

In addition, the switching apparatus also receives, at 404, various flowcontrol signals from the same destination apparatus. Each control signalcorresponds to at least one data packet. Here, a time has elapsedbetween the detection of receipt of each data packet and receipt of acorresponding flow control signal. The port logic module, at 406, trackseach time period between the detection of the receipt of the data packetand the receipt of its corresponding flow control signal. With multipletime periods, the port logic module, at 407, then calculates an averageof the time periods. As used herein, an “average” of a list of numbersis a single number that is meant to typify the numbers in the list.Examples of averages include arithmetic mean and weighted mean.

With the calculated average, the port logic module then compares theaverage to a certain threshold at 408. This threshold can be a timevalue (e.g., in milliseconds), which may be predefined by a user basedon a length of a cable (e.g., Fibre Channel cable) connecting theswitching apparatus to the destination apparatus. The threshold can bebased on the length because the transit time for a data packet to becommunicated from the switching apparatus to the destination apparatusdepends on the length of the cable and therefore, the port logic moduleneeds to be provided a certain threshold to account for the transittime.

Once the comparison is made, the port logic module, at 410, may drop oneor more data packets or forward the data packets in reference to thecomparison. For example, the port logic module may drop the data packetif the average exceeds the threshold, but continue to forward the datapacket if the average falls below the threshold. In one embodiment, asexplained in detail below, the port logic module can drop the datapackets at the output queue. In an alternate embodiment, as alsoexplained in more detail below, the data packets can also be dropped atthe input queue.

FIG. 5 is a timing diagram depicting various data transmitted betweencomponents 102.2, 150, and 102.5 in a Fibre Channel network system 500that supports congestion alleviation, in accordance with an exampleembodiment. In this example, the network system 500 includes a sendingapparatus 102.2, a switching apparatus 150, and a destination apparatus102.5. The sending apparatus 102.2 transmits a data packet 502associated with a particular port to the destination apparatus 102.5 byway of the switching apparatus 150. After receipt of the data packet502, the switching apparatus 150 then receives a buffer-to-buffer credit(B2B) 504 from the destination apparatus 102.5, the buffer-to-buffercredit 504 of which informs the switching apparatus 150 how many datapackets the destination apparatus 102.5 can accept.

At the same time, the switching apparatus 150 tracks the time period 505between the detection of the received data packet 502 and the receipt ofthe buffer-to-buffer credit 504. For subsequent data packets, such asdata packet 502′, the switching apparatus 150 tracks the time period505′ between the detection of the received data packet 502′ and thereceipt of the buffer-to-buffer credit 504′.

At 506, the switching apparatus 150 then calculates an average of thetracked time periods 505 and 505′ and compares this average to a certainthreshold. Based on this comparison, the switching apparatus can controlflow of data packets by dropping one or more data packets 502 and/or502′ destined to destination apparatus 102.5 if needed. For example, ifthe switching apparatus 150 detects that the average exceeds thethreshold, then the switching apparatus drops the data packets 502 and502′ to eliminate or minimize congestion on the other ports. However, ifthe switching apparatus 150 detects that the average falls below thisthreshold, then the switching apparatus 150 forwards the data packet 502and 502′ to the destination apparatus 102.5.

FIG. 6 is a flow diagram depicting a more detailed method 600, inaccordance with an alternative embodiment, for congestion alleviation ina Fibre Channel network system. In this example embodiment, the method600 may be also implemented by the port logic module 310 and employed inthe switching apparatus 150 depicted in FIG. 3.

In reference to FIG. 6, the port logic module initially detects thereceipt of a data packet. For example, at 602, the port logic module canmake such a detection based on detection of receipt of the data packetin an input queue associated with an input port. At 604, this datapacket is then transferred from the input queue to an output queue thatis associated with an output port. The transfer can be by way of alossless mechanism. The port logic module then makes the detection ofthe receipt of the data packet by detecting the storage of the datapacket in an output queue at 606.

Afterwards, the switching apparatus, at 608, checks if flow control isoff. For example, in one embodiment, the switching apparatus can checkwhether a pause command has been asserted. In an alternate embodiment,the switching apparatus can check if buffer-to-buffer credit isavailable (or received from the destination apparatus). Ifbuffer-to-buffer credit is available, then the port logic moduleforwards the data packet to the destination apparatus at 607. However,if buffer-to-buffer credit is not available, then the port logic modulestarts a timer, at 610, to track the time period between the detectionof the data packet and the receipt of buffer-to-buffer credit. Forexample, the port logic module can track based on tracking a number ofcycles an ASIC has a pending data packet without buffer-to-buffercredit.

The port logic module then calculates an average of the time periods. Inone embodiment, the port logic module, at 612, calculates the averageswith the previously calculated averages. That is, the port logic modulecalculates a continuously-updated average that takes into account thelatest tracked time period, which is identified at 610. The port logicmodule then compares, at 614, the calculated average to a certainthreshold, which, as described above, can be pre-defined based on, forexample, the length of a Fibre Channel cable.

In this embodiment, if the average is less than the threshold, asdetermined at 614, then the port logic module checks again, at 615, todetermine whether buffer-to-buffer credit is available. Ifbuffer-to-buffer credit is available, then the port logic moduleforwards the data packet, at 607, to the destination apparatus. Ifbuffer-to-buffer credit is not available, then the port logic modulerepeats the average calculation at 612.

On the other hand, if the port logic module, at 614, identifies that theaverage is greater than the threshold, then the port logic module dropsthe data packet at 616. The port logic module then checks, at 618, ifthere are other data packets in the output queue. If there are datapackets in the output queue, the timer, at 620, can be reset to 0.Alternatively, the timer continues from the current value and datapackets are continuously dropped until output queue becomes empty or abuffer-to-buffer credit, as an example, is received. However, if theoutput queue is empty, the timer can also be reset to 0.

In one embodiment, the port logic module itself can drop data packets atthe output queue. However, in an alternate embodiment, the port logicmodule can drop the data packets at the input queue. For example, inreference to FIG. 3, the port logic module 310 can transmit a request toa queuing module 306, as depicted in FIG. 3, to drop data packetsassociated with a particular port. In particular, on a rising edge of asignal that identifies the average to be greater than the threshold, theport logic module 310 forwards a packet with the output port number ofthe slow port to all queuing modules by way of, for example, multicastfabric channels. The port logic module 310 can append or update theoutput port number in a payload portion of the packet, and this packetis muxed with the regular data path and sent to all downlink modules(including forwarding module).

FIG. 7 is a flow diagram depicting a method 700, in accordance with analternative embodiment, for dropping data packets at the input queue. Inthis example embodiment, the method 700 may be implemented by theforwarding and queuing modules 304 and 306, respectively, and employedin the switching apparatus 150 depicted in FIG. 3. Here, the forwardingmodule, at 702, receives a drop request from a port logic module. Thisdrop request can be a packet with an output port number, as describedabove. Upon receipt of the drop request, the forwarding module 304parses the drop request to retrieve the output port number and providethe output port number to the queuing module 306.

The queuing module, at 704, then checks whether the input queue size isgreater than a threshold. If the input queue size is less than thethreshold, the queuing module will not drop the data packets. However,at 706, the queuing module will drop subsequently received data packetsat the input queue. For example, the queuing module can drop datapackets from the head or tail of the input queue if the input queue sizeis greater than the threshold.

In one embodiment, the queuing module will continue to drop data packetsreceived from the input port until the queuing module receivesinstructions from the port logic module to resume forwarding of datapackets. In another embodiment, the queuing module can be configured tocontinuously drop data packets associated with a particular port as longas the queuing module receives requests on a periodic basis (e.g.,heartbeat messages) from the port logic module to drop the data packets.The periodic time period can be predefined, and the queuing module canstart a timer, as depicted at 708 and 710, with receipt of each datapacket. If the timer does not exceed the threshold, the timer isincremented at 716. However, once the timer has expired at 712, but norequests for dropping the data packets have been received before thetimer has expired, the queuing module is configured to resume forwardingof the data packets to the port logic module at 714.

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules may constitute hardwaremodules. A hardware module is a tangible unit capable of performingcertain operations and may be configured or arranged in a certainmanner. In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry that is temporarily configured bysoftware to perform certain operations. It will be appreciated that thedecision to implement a hardware module mechanically, in dedicated andpermanently configured circuitry, or in temporarily configured circuitry(e.g., configured by software) may be driven by cost and timeconsiderations. Accordingly, the term “hardware module” should beunderstood to encompass a tangible entity, be that an entity that isphysically constructed, permanently configured (e.g., hardwired) ortemporarily configured (e.g., programmed) to operate in a certain mannerand/or to perform certain operations described herein. Consideringembodiments in which hardware modules are temporarily configured (e.g.,programmed), each of the hardware modules need not be configured orinstantiated at any one instance in time.

Modules can provide information to, and receive information from, othermodules. For example, the described modules may be regarded as beingcommunicatively coupled. Where multiples of such hardware modules existcontemporaneously, communications may be achieved through signaltransmission (e.g., over appropriate circuits and buses) that connectthe modules. In embodiments in which multiple modules are configured orinstantiated at different times, communications between such modules maybe achieved, for example, through the storage and retrieval ofinformation in memory structures to which the multiple modules haveaccess. For example, one module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further module may then, at a later time,access the memory device to retrieve and process the stored output.Modules may also initiate communications with input or output devices,and can operate on a resource (e.g., a collection of information).

While the embodiment(s) is (are) described with reference to variousimplementations and exploitations, it will be understood that theseembodiments are illustrative and that the scope of the embodiment(s) isnot limited to them. In general, techniques for congestion alleviationmay be implemented with facilities consistent with any hardware systemor hardware systems defined herein. Many variations, modifications,additions, and improvements are possible.

Plural instances may be provided for components, operations orstructures described herein as a single instance. Finally, boundariesbetween various components, operations, and data stores are somewhatarbitrary, and particular operations are illustrated in the context ofspecific illustrative configurations. Other allocations of functionalityare envisioned and may fall within the scope of the embodiment(s). Ingeneral, structures and functionality presented as separate componentsin the exemplary configurations may be implemented as a combinedstructure or component. Similarly, structures and functionalitypresented as a single component may be implemented as separatecomponents. These and other variations, modifications, additions, andimprovements fall within the scope of the embodiment(s).

What is claimed is:
 1. An apparatus comprising: an output port; a portlogic module in communication with the output port, the port logicmodule having instructions that cause operations to be performed, theoperations comprising; detecting receipt of a plurality of data packetsdestined for the output port that is in communication with a destinationapparatus; receiving, from the destination apparatus, a plurality offlow control signals, each flow control signal corresponding to a datapacket in the plurality of data packets; tracking a plurality of timeperiods, each time period being between the detection of the receipt ofa data packet and the receipt of a corresponding flow control signal;calculating an average of the plurality of time periods; comparing theaverage to a threshold; and dropping at least one of the plurality ofdata packets in reference to the comparison.
 2. The apparatus of claim1, further comprising an output queuing module in communication with theport logic module, the output queuing module includes an output queue,and wherein the operation of detecting the receipt of the plurality ofdata packets comprising detecting that the plurality of data packets isstored in the output queue.
 3. The apparatus of claim 1, furthercomprising an input queue and an input queuing module in communicationwith the input queue and the port logic module, wherein the operation ofdropping the at least one of the plurality of data packets comprisestransmitting a request to the input queuing module to drop the at leastone of the plurality of data packets communicated at the input queue. 4.The apparatus of claim 3, wherein the operation of dropping the at leastone of the plurality of data packets in reference to the comparisonfurther comprises transmitting additional requests on a periodic basisto the input queuing module.
 5. The apparatus of claim 4, wherein theinput queuing module having instructions that cause operations to beperformed, the operations comprising resuming transmittal of additionaldata packets to the port logic module based on non-receipt of theadditional requests for a predefined time period.
 6. The apparatus ofclaim 1, wherein the plurality of flow control signals arebuffer-to-buffer credits, each buffer-to-buffer credit identifies anumber of data packets allowed to accumulate on the destinationapparatus.
 7. The apparatus of claim 1, wherein the plurality of flowcontrol signals are a plurality of pause commands.
 8. Logic encoded onone or more non-transitory, tangible media and when executed causeoperations to be performed, the operations comprising: detecting receiptof a plurality of data packets for a destination apparatus; receiving,from the destination apparatus, a plurality of flow control signals,each flow control signal corresponding to a data packet in the pluralityof data packets; tracking a plurality of time periods, each time periodbeing between the detection of the receipt of a data packet and thereceipt of a corresponding flow control signal; calculating an averageof the plurality of time periods; comparing the average to a threshold;and dropping at least one of the plurality of data packets in referenceto the comparison.
 9. The logic of claim 8, wherein the plurality ofdata packets is received at an input queue and wherein the plurality ofdata packets is dropped at the input queue.
 10. The logic of claim 8,wherein the at least one of the plurality of data packets is destinedfor the destination apparatus by way of an output queue and wherein theat least one of the plurality of data packets is dropped at the outputqueue.
 11. The logic of claim 8, wherein the operation of detecting thereceipt of the plurality of data packets comprises detecting that theplurality of data packets is stored in an output queue.
 12. A methodcomprising: detecting receipt of a plurality of data packets for adestination apparatus; receiving, from the destination apparatus, aplurality of flow control signals, each flow control signalcorresponding to a data packet in the plurality of data packets;tracking a plurality of time periods, each time period being between thedetection of the receipt of a data packet and the receipt of acorresponding flow control signal; calculating an average of theplurality of time periods; comparing the average to a threshold; anddropping at least one of the plurality of data packets in reference tothe comparison.
 13. The method of claim 12, wherein the at least one ofthe plurality of data packets is received at an input queue and whereinthe at least one of the plurality of data packets is dropped at theinput queue.
 14. The method of claim 12, wherein the at least one of theplurality of data packets is destined for the destination apparatus byway of an output queue and wherein the at least one of the plurality ofdata packets is dropped at the output queue.
 15. The method of claim 12,wherein the detection of the receipt of the plurality of data packetscomprises detecting that the plurality of data packets is stored in anoutput queue.
 16. The method of claim 12, wherein the at least one ofthe plurality of data packets is dropped based on the average exceedingthe threshold.
 17. The method of claim 12, wherein the at least one ofthe plurality of data packets is dropped based on the average beingbelow the threshold.
 18. The method of claim 12, wherein the pluralityof flow control signals are buffer-to-buffer credits, eachbuffer-to-buffer credit identifies a number of data packets allowed toaccumulate on the destination apparatus.
 19. The method of claim 12,wherein the plurality of flow control signals are a plurality of pausecommands.